[セッションレポート] Cloud cost optimization: Only paying for what you need (COP207) #reinvent

気になっていたセッション視聴の第二弾です。

セッション概要

Develop a cloud cost-optimization strategy that balances application performance with costs. In this session, learn about strategies for holistic cloud cost optimization, how AWS has improved its cost-optimization recommendation solutions, and how you can use those solutions to map capacity to your needs and make better cost-optimization decisions while maintaining high performance. Hear details on new resource types and optimal resource configurations, how you can identify the right resource configurations using historical data, and specific pricing to consider.

↓↓↓　自動翻訳 ↓↓↓

アプリケーションのパフォーマンスとコストのバランスをとるクラウドコスト最適化戦略を策定します。このセッションでは、クラウドのコストを全体的に最適化するための戦略、AWSのコスト最適化推奨ソリューションの改善方法、およびこれらのソリューションを使用してニーズを満たす容量をマッピングし、高いパフォーマンスを維持しながらより良いコスト最適化の決定を行う方法について学習します。新しいリソースの種類と最適なリソース構成、過去のデータを使用して適切なリソース構成を特定する方法、および考慮すべき特定の価格についての詳細を説明します。

セッション内容

The visibility journey（可視化の旅）

最適化は可視化の旅から始まる

可視化の旅の中でも、Safeguards ※ は困難で、重要なターニングポイントになります。また Governance で用いるタグ戦略が不足していると Optimization に悪影響を与えます。

• Chaos
• Awareness: 意識・問題認識
• Safeguards
• Governance
• Optimization

※ 管理を行う方法やメカニズム

『所感』
まずは見える（＝把握）状態とするということは大切です。パフォーマンス改善する際の文脈などで「推測するな計測せよ」という格言がありますが、コストにおいても、まずは目標や対象を明らかにし、現状把握や評価するために計測するところから始まるのと同じことですね。

Optimization methods（最適化方法）

これらの複数の方法を同時に、組み合わせて実施することで、多くの節約が得られるため、クラウド最適化の重要な部分です。

• Discounts: SP や RI, EDP（Enterprise Discount Program）による割引
• Deleting: 不要な EBS ボリュームや EIP の削除
• Rightsizing: Compute Optimizer によるサイジング、 Auto Scaling やコンテナを利用したスケーリングによりワークロードのリソースに柔軟性を持たせる
• Suspending: 夜間や週末など利用しない時間にワークロード・リソースを停止

『所感』
これらの4つの観点・方法は、AWS におけるコスト最適化のポイントとして広く知られているものかと思います。セッション内のアンケート結果へのコメントにもあったように Discounts は基本的にはワークロードに変更が必要がなく・効果も大きいため、最初に検討されるケースが多いかと思いますが、個人的には冒頭にあった可視化の旅のようなある程度ワークロードの状況が明確になった後がお勧めです。不要なリソースや適正なサイジングがなされないまま、誤ったコミットを行うリスクがあるためです。

最適化方法の実装

Rightsizing と Suspending を組み合わせることで 86% 節約出来ます。ただしこれが（停止する期間がないような）本番環境だと異なってきます。

• Compute Optimizer を使用して、適切なサイズへ変更（m5.4xlarge → m5.xlarge）
• 利用されていない夜間帯を停止（am 12:00 - am 06:00）

Suspending が適さないワークロードでは代わりに Discounts を組み合わせます。

• Compute Optimizer を使用して、適切なサイズへ変更（m5.4xlarge → m5.xlarge）
• 長期的な利用をコミット

『所感』
図解してもらうとわかりやすいですね。実際には、ここまで単純ではないかもしれませんが、それぞれのワークロード特性によって、4つの手段を組み合わせることで最適化を実施していくわかりやすい例だと思いました。

RI/SP 購入のすゝめ

コストを、二つのタイプにわけ Predictable usage 部分に RI/SP を適用します。ワークロードが成長する中で Volatile usage と Predictable usage の比率が変化していくため、RI/SP の範囲を調整していきます。

• Volatile usage: 動的な部分で予測が難しい部分
• Predictable usage: 予測可能な（見込みが立つ）部分

RI/SP を段階的に小規模で購入していくことを推奨します。これは一括で購入するよりも、再評価するタイミングを多く得ることができ、柔軟性を高めることが出来るためです。

『所感』
意図的に小規模に購入していくアプローチは、興味深いです。最初は少しだけ購入することはありますが、それは様子見の要素が強く問題なければ次は大きく購入する流れが多かったため、そういったアプローチもあるのかを発見でした。継続的に小規模に購入していくアプローチは rolling Savings Plans として AWS Blog でも詳細に紹介されています。ただ、社内でシェアした際にも指摘があったのですが、短いスパンで購入していくことの運用負担が高くなるのでは？という懸念もあります。おそらく、実現するには購入範囲のレコメンドや購入支援サービス、一連のプロセスまたはチームが必要ということなのかと考えています。

• How can I use rolling Savings Plans to reduce commitment risk?

The Fidelity story（事例： Fidelity Investments）

クラウドコストから最大限の価値を引き出せるようにすること

クラウド導入の中で、FinOps プラクティスを設定し、中央チームを設置し、判断・共有を行なっていくことで、クラウドに掛かるコストから最高の価値を得られるようにすることを目標にしました。

• FinOps とは

FinOps プラクティスを確立するために

FinOps フォーカスと呼んでいるプラクティスを確立するためのカテゴリーを定義して、段階的に進めていきました。

• Culture of accountability(説明責任を果たす文化)
  • Empower product teams to manage cost and workload
    (製品チームがコストとワークロードを管理できるようにする)
• IT optimization(ITの最適化)
  • Only utilize what we need when we need it
    (必要なときに必要なものだけを利用する)
• Purchasing strategies(購買戦略)
  • Increase the value of purchased cloud service products
    (購入したクラウドサービス製品の価値を高める)
  • 最初は割引（Discounts）の部分に KPI を設定
• Financial controls(財務管理)
  • Establish consistent financial controls, processes, and measurements
    (一貫した財務管理、プロセス、および測定方法を確立する)
• Cost transparency(コストの透明性)
  • Ensure that our cost data is believable, visible, and consumable
    (コストデータの信頼性、可視性、消費可能性を確保する)
  • タグ付けとポリシーを実施、サードパーティ製品による可視化

Discount をテーマにした3つの KPI を定めました。これらを達成することで、必要な対象が割引されていることを把握します。

• Unit discount
  • % discount of RI-eligible services
    (RI 適格サービスの割引率, RI coverage と Spot coverage により得られる割引）
• RI coverage
  • % of eligible services covered by RIs
    (RI の対象範囲)
  • 予約した時間を Spot Instance を除いたサービスのトータル利用時間で割った
• Spot coverage
  • % of compute deployed as Spot Instances
    (Spot Instance 利用率)

最適化を進めるために、翌年に KPI を進化させました。 Discount はそのままに Deleting と Suspending を検討します。

• Purchasing effectiveness (予約による効果) / Discount
  • Cost discount of eligible services
    (対象サービスのコスト割引）
  • 2020年の KPI 3つをまとめた KPI
• Unutilized resources(利用していないリソース) / Corverage
  • % of cloud accounts with automated cleanup policy
    (自動クリーンアップポリシーが適用されたクラウドアカウントの割合)
  • 未使用のリソースを調査し、それらを自動的に処理する仕組みがあるかを確認し、稼働状況を測る
• Underutilized assets(十分に活用されていない資産) / Utilization
  • % increase or compute utilization
    (コンピュート使用率の増加率または減少率)
  • 適切な対象が RI 予約効果が得ているか精査するために CPU Utilization をベースに十分に稼働しているかを確認

3年目になると KPI の内容を少し変更しています。

• Purchasing effectiveness (予約による効果) / Discount
  • Discount は重み付け（Weight）を変更
• Unutilized resources(利用していないリソース) / Corverage
  • % of cloud accounts with automated shutdown policy
    (自動シャットダウンポリシーを利用しているアカウントの割合)
  • 週末にインスタンスを停止する仕組みを導入
• Underutilized assets(十分に活用されていない資産) / Utilization
  • Utilization of compute instances, using memory and CPU metrics
    (メモリとCPUの指標を使用した、コンピュートインスタンスの利用率)
  • CPU だけは評価指標として不足しているとのフィードバックからメモリを追加し、ワークロードにより使い分けてもらえるようにした

『所感』
FinOps プラクティスを実践する一連のジャーニーが紹介されていて、実際にどのように進めていくかをイメージすることが出来ました。また何度か言われていた中央チーム（CCoEのような）を設けるというのも本格的に実施するには必要な機能なのだなと改めて感じました。中央チームから一方的な形ではなく、協力的にアプローチしフィードバックを得て、改善サイクルを実行することで、組織に文化として根付くという点の重要さも再確認しました。

AWS Compute Optimizer updates(Compute Optimizer アップデート)

• AWS Compute Optimizer は 2019年秋にリリース
• 非常に多くある EC2 インスタンスタイプからワークロードに最適なインスタンスを推奨
• ダウンタイムなく変更可能な EBS ボリュームの検討から始めることがお勧め

4つのパートナー製品からデータを連携することが可能になりました。以前はメモリ情報を取得するために CloudWatch Agent が必須でしたが、今回のアップデートでパートナー製品からの取得が可能になります。メモリ情報を取得することで、より広い選択肢での推奨が可能となります。

• AWS Compute Optimizer で可観測性パートナーが提供する外部メトリクスをサポート

『所感』
パートナー製品からメトリックが連携されるのは、既に製品を利用されている方にとっては有用なアップデートではないかと思います。

DevelopersIO でもアップデートの紹介やその他にも Compute Optimizer の記事が書かれているので、ご興味があればご一読いただけると幸いです。

• DevelopersIO / AWS Compute Optimizer

所感

コスト最適化の4つの方法（Discounts, Deleting, Rightsizing, Suspending）を改めて体系的に知ることが出来たセッションでした。
Fidelity Investments 社の事例は個人的には得るものが多く、また実践するのに数年（まだ道のりは途中とのことでしたが）かかっていることも重要な点の一つではないかと感じました。単純にコスト削減だけであればここまで時間は要さないと思いますが、制限し過ぎて開発者のアジリティを損ねないようにしながら KPI を設け目標を可視化し、組織に文化として根付かせるという道のりは短期的ではなく長期的な課題として取り組むものなのだと再確認しました。